Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.
При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:
Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.
Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.
Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).
Эти блоки и нужно скопировать во время паузы FSR:
До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:
Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:
Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:
Глобальная конференция VeeamON 2020 не будет проводиться в Америке физически, а пройдет онлайн, как и все остальные подобные события. И что самое приятное - она будет полностью бесплатна для всех. Таги:
На портале VMware Learning появились новые лабы (они же Hands-on Labs), которые посвящены новой версии платформы VMware vSphere 7:
Напомним, что лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.
В этих лабораторных работах содержится около трех часов контента, с помощью которого вы сможете узнать обо всех нововведениях vSphere 7 в деталях. Скоро также обещают и лабы по vSphere 7 with Kubernetes, что будет очень полезно, так как многие пользователи не могут попробовать контейнеризованные приложения в своей виртуальной инфраструктуре.
Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов
(Partition Layout), которые произошли в VMware ESXi 7.
Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.
Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.
В VMware vSphere 6.x структура разделов выглядела следующим образом:
Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.
В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:
Теперь в ESXi 7 есть следующие 4 раздела:
System boot - хранит boot loader и модули EFI. Формат: FAT16.
Boot-banks (2 штуки)
- системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.
Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.
В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:
Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.
Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).
Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:
В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:
Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):
Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.
Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.
ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:
Boot media размером минимум 8 ГБ для устройств USB или SD
32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
Boot device не может быть расшарен между хостами ESXi
Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.
Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...
Некоторым администраторам может понадобиться PowerCLI-сценарий, с помощью которого можно подсчитать число гостевых операционных систем в виртуальных машинах инфраструктуры VMware vSphere. Stuart в своем блоге рассказал про интересный скрипт, с помощью которого это можно сделать.
Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:
$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count
Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:
После этого он сделал скрипт, который собирает в таблицу типы гостевых ОС и увеличивает счетчик, если они встречаются среди виртуальных машин снова при прогоне цикла:
В этой таблице все в порядке, кроме последней строчки - в нее набиваются гостевые ОС, для которых тип не был обнаружен. Поэтому автор добавил следующие строчки с именами ВМ, чтобы добавить значение Unknown таким машинам:
# Added this to the beginning of the script
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
# Added this to the foreach loop section
IF ($OSName -eq $NullOS){$OSName = "Unknown"}
Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.
На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:
Вот все корневые разделы этого руководства:
Persistent memory (PMem), including using PMem with NUMA and vNUMA
Getting the best performance from NVMe and NVME-oF storage
AMD EPYC processor NUMA settings
Distributed Resource Scheduler (DRS) 2.0
Automatic space reclamation (UNMAP)
Host-Wide performance tuning (aka, “dense mode”)
Power management settings
Hardware-assisted virtualization
Storage hardware considerations
Network hardware considerations
Memory page sharing
Getting the best performance from iSCSI and NFS storage
Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.
Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.
Компания VMware объявила о том что продляет поддержку (General Support) для платформы VMware vSphere версии 6.7 до 15 октября 2022 года. Напомним, что ранее эта поддержка была заявлена до 15 ноября 2021 года. Таким образом, срок действия поддержки General Support был продлен на 11 месяцев.
General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится довольно долгое время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя), получают апдейты и апгрейды, багофиксы и исправления безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.
Дата наступления EoTG (End of Technical Guidance) останется неизменной - это 15 ноября 2023 года. В рамках этой фазы, которая начинается с момента окончания General Support, предоставляются инструкции через портал самообслуживания, а по телефону звонки уже не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.
Более подробно о сроках поддержки и Technical Guidance для продуктов VMware можно прочитать в документе "VMware Lifecycle Product Matrix".
Как знает большинство администраторов VMware vSphere, у данной платформы есть очень удобная сущность Content Library, которая позволяет хранить контент различного типа (скрипты, ISO-образы, текстовые файлы), в том числе шаблоны виртуальных машин. В обновленном решении VMware vSphere 7 появилось несколько новых возможностей по работе с библиотеками, о которых мы рассказывали вкратце, а сегодня поговорим подробнее.
Первое важное нововведение - представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для работы с версиями шаблонов и возможностью откатиться к предыдущей версии.
Ранее при работе с шаблонами в формате VM Template (*.vmtx) администратор vSphere должен был выполнить следующую последовательность действий:
Конвертировать шаблон в виртуальную машину
Сделать снапшот ВМ на случай того, что что-то пойдет не так
Обновить гостевую ОС или другие настройки ВМ
Конвертировать ВМ назад в шаблон
Скопировать шаблон обратно в Content Library
Удалить старый шаблон из библиотеки
Теперь это все выглядит гораздо проще. Для внесения изменений в шаблон нужно сделать просто Check-Out его из библиотеки:
Этот процесс вовлекает последовательность действий, но даже во время нее можно развертывать новые ВМ из этого шаблона (просто остальные пользователи не могут сделать Check-Out).
Далее администратор может изменять шаблон и чекинить его обратно в библиотеку, а также создавать новые версии этого шаблона, чтобы можно было использовать несколько модификаций одного шаблона. Также при Check-In шаблона можно указать, что в нем изменилось, чтобы другие пользователи были в курсе:
После этого создается цепочка версий с временными метками, где можно отслеживать всю историю изменений шаблона ВМ:
Версионирование позволяет откатиться к любой версии шаблона, а также удалить ее из цепочки:
Кроме того, теперь у Content Library появились расширенные настройки (Advanced Configuration), доступ к которым можно получить вот тут:
Сами настройки выглядят так (можно выбрать один из серверов vCenter, где изменяются настройки):
Обратите внимание, что для применения некоторых настроек нужно будет перезагрузить сервис Content Library. Делается это из интерфейса vCenter Appliance Management Interface (VAMI). Для этого вас перенаправят на страницу https://<vCenterServer-FQDN>:5480:
Также в vSphere 7 был улучшен механизм привилегий для библиотек контента:
Ну и напоследок отметим, что еще в PowerCLI 11.5 появилось несколько новых командлетов для управления библиотеками контента. В PowerCLI 12 все еще лучше.
Мы много писали о новых возможностях платформы VMware vSphere 7, но невозможно рассказать обо всех ее нововведениях в одной статье. Сегодня мы расскажем об одной интересной штуке - компоненте Watchdog Timer, который мы упоминали в одном предложении в статье о новых фичах.
Теперь для виртуальных машин доступно специальное устройство virtual watchdog timer (vWDT), которое позволяет администраторам в унифицированном виде узнавать о том, что гостевая операционная система и приложения данной ВМ зависли или вывалились в синий экран. Это особенно важно для кластеризованных приложений в целях поддержания их доступности.
В случае если гостевая ОС и приложения зависли, Watchdog позволяет обнаружить это и среагировать определенным образом, например, перезагрузить машину. Для этого есть механизм таймера обратного отчета, который должен сбрасываться в нормальном режиме функционирования системы.
Это виртуальное устройство пробрасывается в гостевую ОС через механизм BIOS/EFI ACPI и настраивается на уровне гостевой системы или самого BIOS/EFI.
Таблица Watchdog Resource Table (WDRT) имеет несколько регистров, в которые можно записать значения таймера, действия по их истечению и другие параметры. Большинство современных ОС поддерживают интеграцию с таблицей Watchdog Action Table (WDAT), определяющей список доступных действий для таймеров, которые и использует компонент WDRT.
Вот список доступных инструкций WDAT:
WATCHDOG_ACTION_RESET
WATCHDOG_ACTION_QUERY_CURRENT_COUNTDOWN_PERIOD
WATCHDOG_ACTION_QUERY_COUNTDOWN_PERIOD
WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD
WATCHDOG_ACTION_QUERY_RUNNING_STATE
WATCHDOG_ACTION_SET_RUNNING_STATE
WATCHDOG_ACTION_QUERY_STOPPED_STATE
WATCHDOG_ACTION_SET_STOPPED_STATE
WATCHDOG_ACTION_QUERY_REBOOT
WATCHDOG_ACTION_SET_REBOOT
WATCHDOG_ACTION_QUERY_SHUTDOWN
WATCHDOG_ACTION_SET_SHUTDOWN
WATCHDOG_ACTION_QUERY_WATCHDOG_STATUS
WATCHDOG_ACTION_SET_WATCHDOG_STATUS
Для большинства современных серверных ОС Windows и Linux не требуется каких-либо действий для дополнительной настройки таймера, но они могут понадобиться для некоторых старых систем, а FreeBSD или Mac OS X вовсе не поддерживают Watchdog Timer. Вот в целом информация о его поддержке:
Windows 2003 поддерживает Watchdog Resource Table (WDRT)
Windows 2008 и более поздняя поддерживает Watchdog Action Table (WDAT).
Гостевая ОС не требует дополнительной конфигурации.
Linux-дистрибутивы, такие как Ubuntu 18.04 и Red Hat Enterprise Linux 7.6, на базе ядра 4.9 или более позднего поддерживают Watchdog Action Table (WDAT).
Для этого нужен драйвер wdat_wdt.ko.
Для настройки вам понадобится виртуальная машина с VM hardware версии 17 (появилось в vSphere 7). Надо просто добавить устройство Watchdog Timer:
Как вы видите, виртуальный Watchdog Timer можно включить либо на уровне BIOS/EFI (тогда он будет запускаться до старта ОС), либо на уровне гостевой ОС. Помните, что если гостевая ОС не поддерживает это устройство, то машина будет постоянно перезапускаться по команде от устройства Watchdog.
В vSphere Client видна информация о статусе исполнения Watchdog Timer. Не запущен:
Не так давно мы писали о новом релизе архитектуры VMware Cloud Foundation 4.0, которая представляет собой комплексное программное решение, включающее в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
В рамках новой версии VCF 4.0 была анонсирована поддержка архитектуры контейнеров приложений в виртуальных средах VMware vSphere with Kubernetes (ее эволюцией является нативная платформа Project Pacific). С этого момента, чтобы обеспечить поддержку контейнеров, пользователям VCF приходилось иметь минимум 7 серверов - 4 сервера для домена управления VCF Management Domain и 3 сервера для Virtual Infrastructure (VI) Domain.
Теперь домен VI можно размещать в рамках домена VCF Management, что сокращает число минимально необходимых хостов до четырех:
Таким образом, теперь VCF поддерживает 2 архитектуры:
Consolidated architecture - один кластер vSphere развертывается как часть Management Domain. Пулы ресурсов позволяют изолировать управляющие нагрузки (экземпляры vCenter, NSX Manager, SDDC Manager и т.п.) от нагрузок виртуальных машин. В этом случае нужно минимум 4 хоста для управляющего домена.
Standard architecture - управляющие нагрузки и виртуальные машины исполняются на разных хостах в разных доменах рабочей нагрузки. ВМ развертываются в отдельных кластерах vSphere, которые работают в рамках доменов Virtual Infrastructure (VI) domains. Это позволяет не только отделить среды на физическом уровне, но и разнести их по разным окружениям разных экземпляров vCenter. Такая архитектура считается рекомендуемой. В рамках окружения VCF можно развернуть до 14 доменов VI и один Management Domain, каждый домен может иметь несколько кластеров в vSphere (в каждом кластере минимум 3 хоста).
Цифра 0 в номере апдейта намекает на то, что ничего особо нового в обновлении нет, что соответствует действительности - было исправлено лишь несколько мелких ошибок и одна важная.
Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.
Скачать VMware vCenter 7.0 Update 0a можно по этой ссылке.
Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:
Службы Tanzu Kubernetes Grid Service for vSphere:
Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
Kubernetes 1.17.4
С версии Kubernetes 1.16.x можно обновиться на 1.17.x
Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.
Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.
Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:
Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:
После этого данный образ появится в списке:
Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:
Выбираем образ, который мы хотим привязать к бейслайну:
После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:
После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):
Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.
Если ничего критичного не нашлось, жмем на кнопку Remediate:
Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:
В консоли вы увидите, что ESXi 7.0 установлен:
То же самое будет и в vSphere Client:
Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.
Вильям Лам написал интересную заметку о том, как пробросить USB-клавиатуру или мышь хоста ESXi (они называются USB HID Devices) в гостевую ОС виртуальной машины на VMware vSphere.
Такое может понадобиться, например, когда требуется пробросить в конкретную ВМ отдельную пару USB-устройств ввода (клавиатура+мышь), помимо выделенного устройства vGPU. Также некоторые другие устройства (например, датчики температуры) также притворяются HID-девайсами. Хост ESXi в этом случае по умолчанию не считает необходимым подцеплять такие устройства никуда.
Это поведение можно изменить, добавив следующие параметры в VMX-файл виртуальной машины (или ее Advanced Settings):
Вторая вещь, которая вам может понадобиться - это проброс USB-устройств Chip Card Interface Devices (CCID) в виртуальную машину (например, ридер смарт-карт). Для этого в VMX нужно добавить следующие строчки:
Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.
Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:
В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:
Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.
Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion
виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.
После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:
Казалось бы, мелочь, но иногда может сэкономить немного времени администратора. Для работы этой фичи нужно, чтобы оба хоста VMware ESXi были седьмой версии или выше.
На сайте проекта VMware Labs появилась обновленная версия мобильного клиента для управления виртуальной инфраструктурой VMware vSphere - vSphere Mobile Client 1.11.
Напомним, что в прошлый раз мы писали о возможностях Mobile Client версии 1.9, поэтому ниже мы посмотрим, что нового появилось в последних двух версиях - 1.10 и 1.11.
Виртуальная клавиатура для консоли ВМ, включая специальные клавиши. Наконец-то, системные администраторы смогут выполнять простейшие задачи внутри гостевой системы.
Для кластеров появилась страница с их деталями, чего тоже очень ждали.
Для iOS-устройств появился прямой доступ к консоли ВМ (по-прежнему, требуется и прямой доступ с устройства к серверу ESXi).
Хост больше не показывается как Standalone, когда является частью кластера.
Более корректная обработка статусов для объектов (алармы и проблемы в конфигурации).
Правильный подсчет vCPU на странице свойств ВМ.
Все страницы детальной информации об объектах теперь сделаны в едином стиле.
Улучшена поддержка старых мобильных устройств.
Исправлено множество ошибок самого разного плана.
Скачать vSphere Mobile Client 1.11 можно по этим ссылкам:
Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.
Еще в версии VMware vSphere 6.7 появилась интересная новая возможность платформы виртуализации - перезагрузка гипервизора без рестарта всего хоста ESXi. Очевидно, что главное преимущество такого подхода - уменьшенное время на загрузку серверов, некоторые из которых грузятся ну ооочень долго.
Ведь для некоторых обновлений и патчей необязательно аппаратно перезагружать хост и реинициализировать все его оборудование, что происходит при стандартной загрузке (процесс power-on self-test, POST). Достаточно лишь перезагрузить программную часть платформы.
Возможность быстрой перезагрузки ESXi Quick Boot может быть использована компонентами vSphere Update Manager или vSphere Lifecycle Manager (vLCM).
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по этому поводу приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
Для корректной работы Quick Boot есть и некоторые ограничения. Если вы используете vSphere 6.7, то Quick Boot не будет работать, если у вас включен TPM, есть устройства passthru, а также загружены драйверы vmklinux. Для версии vSphere 7.0 ограничением является только включенный TPM.
Для проверки хоста ESXi на совместимость с Quick Boot нужно выполнить следующую команду в консоли (она выведет полный список факторов, препятствующих использованию быстрой загрузки, таких как драйверы, оборудование и т.п.):
/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
Включить быструю загрузку можно в настройках Update Manager или Lifecycle Manager через vSphere Client или Web Client (этот клиент доступен только для vSphere 6.7):
Не так давно мы писали о той функциональности, которой уже нет в VMware vSphere 7, а также о том, какие фичи находятся в состоянии Deprecated. Это значит, что они пока еще есть в текущем релизе, но уже точно будут отсутствовать в следующей версии платформы. Одной из таких фич стала аутентификация Integrated Windows Authentication (IWA), она же "встроенная проверка подлинности Windows".
IWA - это механизм, который позволяет аутентифицироваться через встроенную аутентификацию ОС в сервисах сервера vCenter, который подключен к домену Microsoft Windows Active Directory (AD).
Депрекация этого механизма в vSphere 7 означает, что вы все еще можете смигрировать настройки IWA при апгрейде vCenter, а также развернуть его с нуля. После этого IWA позволит пользователям аутентифицироваться на vCenter.
Почему поддержка IWA уходит из vSphere? Ответ прост - раньше vCenter работал на платформе Windows как приложение для этой ОС с соответствующими возможностями доступа к ее функциям и сервисам AD, теперь же это виртуальный модуль (vCenter Server Appliance), который работает на базе Linux (а точнее Photon OS) и не может быть нативной частью домена.
Какие альтернативные способы можно использовать для аутентификации в домене AD:
С использованием LDAP. Контроллеры домена предоставляют сервисы LDAP, которые может использовать vCenter.
С использованием нового механизма Identity Federation (появился в версии vSphere 7). Эту возможность можно применять для соединения vCenter к Active Directory Federation Services (ADFS) с использованием протоколов OAUTH2 и OIDC.
VMware также объясняет, что присоединение vCenter к инфраструктурам, которые зависят от этого vCenter, может потенциально создать проблемы зависимостей: контроллер домена зависит от включенного в него vCenter как виртуальная машина, а vCenter зависит от домена как его член.
Еще одна причина депрекации IWA - "политическая". Некоторые крупные организации имеют очень строгие правила для администраторов по заведению новых систем в домен и обслуживанию его жизненного цикла. Нередка ситуация, когда администраторы vSphere, которые имеют право включать vCenter в домен, получают бан аккаунта от безопасников, которые отключают его за неактивность.
Аналогичный подход к депрекации IWA компания VMware сделала и для серверов ESXi - они будут поддерживать взаимодействие с доменом на тех же условиях, что и vCenter. Правами доступа к хост-серверам ESXi можно управлять через стандартный механизм Role-Based Access Controls (RBAC) на сервере vCenter.
Поэтому по совокупности причин было решено отказаться от IWA в пользу более гибкого механизма LDAP/LDAPS.
Кстати, если вы видите в логе контроллера домена событие Event 2889 при использовании IWA, то обратитесь к статье KB 78644.
Чтобы переключиться на новый способ аутентификации нужно вывести серверы из домена по старой схеме и включить интеграцию по новой. Вот, например, видео о том, как смигрировать аутентификацию с LDAP на более защищенный протокол LDAPS:
Перед переходом всей инфраструктуры на новый способ аутентификации нужно обязательно протестировать сам метод в тестовой инфраструктуре. Ну а когда будете делать перевод продакшена, не забудьте сделать снапшот сервера vCenter - если что на него можно будет откатиться с сохранением старых настроек.
Таги: VMware, vSphere, Security, vCenter, ESXi, Microsoft
Более-менее заметные изменения появились только в vCenter 6.7 U3g:
Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
Обновления Photon OS, о которых можно почитать вот тут.
Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).
Коллеги из Veeam поделились интересной новостью. Во-первых, и это очевидно, что глобальная конференция VeeamON 2020 не будет проводиться в Америке физически, а пройдет онлайн, как и все остальные подобные события. И, во-вторых, что самое приятное - она будет полностью бесплатна для всех.
Дата проведения: 17-18 июня 2020 года. Регистрация по этой ссылке.
Ежегодная конференция VeeamON - одно из крупнейших мероприятий ИТ-отрасли. На VeeamON соберутся ведущие ИТ-эксперты и альянс-партнеры Veeam, такие как VMware, NetApp, Hewlett Packard Enterprise и многие другие.
В рамках двухдневного онлайн-мероприятия компания Veeam расскажет о новой стратегии компании (напомним, она была продана фонду Insight Partners в этом году за 5 миллиардов долларов), покажет все свои самые новые продукты в сфере защиты данных и обеспечения виртуальных датацентров, а также раскроет множество технических деталей, интересных администраторам платформ виртуализации VMware vSphere и Microsoft Hyper-V.
Список главных спикеров конференции:
William H. Largent - CEO and Chairman of the Board, Veeam Software
Danny Allan - CTO and Senior Vice President, Product Strategy, Veeam Software
Jim Kruger - Chief Marketing Officer, Veeam Software
Anton Gostev - Senior Vice President, Product Management, Veeam Software
Специальный гость - Tripp Crosby,
Entertainer & Comedian.
Ну а для тех, кому хочется послушать о самых актуальных новостях Veeam этого года на русском языке, пройдет также бесплатная онлайн-конференция VeeamON Tour 2020.
Дата проведения: 25 июня 2020 года.
Программа конференции:
11:00 Вступительное слово. Василий Ваганов, Вице-президент, Северная и Восточная Европа, Ближний Восток, Россия и СНГ
11:05 Veeam в 2020: Новости и прогнозы. Владимир Клявин, Региональный Директор, Россия и СНГ, Veeam Software
11:25 Пленарная сессия — Технологии. Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
11:45 Технические сессии:
Лучшие практики и рекомендации для успешной работы с Veeam Agents - Сергей Пискунов, технический консультант Veeam Software
Реализация Veeam NAS Backup в версии 10 - Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
12:05 Перерыв
12:20 Технические сессии:
Практические рекомендации по защите данных от программ вымогателей - Павел Косарев, технический консультант Veeam Software
Все об интеграции с СХД и новые возможности Veeam v10 - Роман Прытков, технический консультант Veeam Software
12:40 Технические сессии:
Рекомендации по планированию инфраструктуры Veeam Backup & Replication v10 - Евгений Зосимов, технический консультант Veeam Software
Как вы знаете, обновлением виртуальной инфраструктуры в VMware vSphere 7 вместо Update Manager теперь занимается комплексное средство vSphere Lifecycle Manager (vLCM). vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений.
Одной из возможностей этого средства является функция проверок на совместимость (Compatibility Checks). Они нужны, например, в случаях, когда вы настроили интеграцию Hardware Support Manager (HSM) для серверов Dell или HP и хотите проверить оборудование развертываемого сервера на совместимость с ESXi. Это так называемые Hardware Compatibility Checks.
Во время проверок можно использовать кастомный образ ESXi с дополнениями Firmware и Drivers Addon для проверки образов от поддерживаемых вендоров на совместимость с имеющимся у вас оборудованием и установленной версией микрокода. Вот так в vLCM выглядит проверка соответствия для образов ESXi:
На этом скриншоте видно, что текущий уровень компонентов хоста ESXi не соответствует желаемым параметрам в плане версий Firmware аппаратных компонентов. В этом случае есть опция Remediate (кнопка вверху слева), которая позволяет привести хосты ESXi в соответствие, обновив микрокод аппаратных компонентов средствами Hardware Support Manager - и все это прямо из клиента vSphere Client, без сторонних консолей.
vLCM предоставляет также функции автоматической проверки (HCL Automatic Checks), с помощью которых можно автоматически и систематически искать несоответствия уровня firmware на хостах ESXi и сверять их с актуальной онлайн-базой VMware Compatibility Guide (VCG, он же Hardware Compatibility Guide - HCL).
Если вы зайдете в раздел Cluster > Updates, то увидите результат работы автоматического тестирования на совместимость с необходимыми деталями. Пока это доступно только для контроллеров хранилищ vSAN (storage controllers), что является критически важной точкой виртуальной инфраструктуры с точки зрения обновлений (стабильность, производительность).
На скриншоте ниже показаны результаты проверки совместимости в кластере для адаптера Dell HBA330. В данном случае видно, что на всех хостах установлена одинаковая и последняя версия firmware, что и является правильной конфигурацией:
По ссылке "View in HCL" вы сможете увидеть, что данный адаптер с данной версией микрокода действительно поддерживается со стороны VMware vSphere и vSAN.
Как вы все знаете, недавно компания VMware сделала доступной для загрузки платформу VMware vSphere 7, где службы управляющего сервера vCenter доступны уже только в формате виртуального модуля vCenter Server Appliance (vCSA).
Блоггер Ozan Orcunus написал интересную заметку о том, как можно отключить автозагрузку некоторых сервисов в vCenter 7. Не секрет, что с каждой новой версией vCenter становится все более и более прожорливым в отношении системных ресурсов. Например, для 10 хостов ESXi и 100 виртуальных машин теперь уже требуется сделать vCSA с двумя vCPU и 12 ГБ оперативной памяти, что слишком много для тестовых окружений, например, на ноутбуке.
Поэтому чтобы vCSA работал немного побыстрее в тестовых средах (и только там, в продакшене этого делать не рекомендуется) можно отключить некоторые его службы при загрузке. В KB 2109881 написано, как останавливать и запускать службы vCenter с помощью команды service-control, но нигде официально не написано о том, как отключать их при старте vCenter.
А делается это следующим образом:
1. Логинимся по SSH на сервер vCSA и переходим в каталог /etc/vmware/vmware-vmon/svcCfgfiles/.
2. Большинство сервисов vCenter - это не стандартные сервисы systemd, а службы спрятанные за за сервисом VMware Service Lifecycle Manager (vmware-vmon). Наберите "systemctl status vmware-vmon" и посмотрите на результат:
Конфигурация сервисов спрятана в JSON-файлах - в директориях, которые можно увидеть в выводе команды. Например, чтобы отключить службу Content Library, нужно открыть файл конфигурации командой:
vi vdcs.json
И выставить в нем параметр StartupType как DISABLED.
3. После внесения всех необходимых изменений нужно перезагрузить vCSA для применения настроек автозапуска.
4. После этого идем в раздел Services и видим, что автозапуск некоторых служб vCenter отключен:
При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:
В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:
В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:
Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000
После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:
После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:
Обратите внимание, что такая конфигурация не поддерживается в производственной среде! Поэтому используйте такие виртуальные ESXi 7 только для тестирования и других некритичных задач.
Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.
С давних пор для синхронизации времени в виртуальных машинах VMware vSphere использует протокол NTP, который обеспечивает точность синхронизации на уровне миллисекунд. Для большинства систем этого вполне достаточно, но есть и класс систем, где нужна точность на уровне микросекунд при обработке последовательности событий - например, для финансовых приложений, торгующих на бирже, где важен порядок ордеров в стакане.
Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.
Протокол NTP обладает следующими особенностями:
Имеет точность на уровне единиц миллисекунд.
Реализуется полностью программно, как для таймстемпинга приема сигналов точного времени, так и для таймстемпинга пользовательского уровня для передачи событий.
Широко распространен и является индустриальным стандартом синхронизации времени.
Работает несколько десятилетий, дешев, прост и надежен.
Клиенты NTP включены во все компьютеры, серверы и роутеры, а также множество программных продуктов.
Может синхронизировать время от самых разных источников - атомные часы, GPS-ресиверы, а также разные серверы, разбросанные по интернету.
Клиент-серверная архитектура, позволяющая использовать несколько серверов для синхронизации.
Возможности коррекции и отказоустойчивости - клиент может забирать время с нескольких серверов и исключать из них тот, который находится географически далеко и отвечает с задержкой сигнала.
NTP - это юникаст-протокол, который не требует особых правил маршрутизации. Пакеты получает только источник и отправитель.
Для виртуальных машин у NTP есть следующие особенности:
Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
NTP работает на порту 123.
NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.
Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):
PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.
Вот так это выглядит:
Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
Использует 2 UDP-порта - 319 и 320.
В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
В рамках одной сети через PTP все ее виртуальные машины получают точное время.
В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:
Если у вас нет специальных задач под PTP, то старого доброго NTP вполне достаточно. Он надежный и отказоустойчивый.
Для PTP нужно специальное оборудование, появляется мультикастовый трафик, и требуется изменение сетевых настроек, что вызывает необходимость в дополнительных затратах по настройке инфраструктуры. Очевидно, что развертывать его нужно только в случае появления у приложений в виртуальных машинах требования к точности времени на уровне микросекунд.
Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:
Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).
Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.
Если вы получаете вот такое сообщение об ошибке:
.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
Значит нужно в свойствах скрипта разблокировать его:
Как все уже знают, недавно компания VMware выпустила обновление своей флагманской платформы VMware vSphere 7. Одновременно с этим были выпущены новые версии и других продуктов серверной и десктопной линеек.
Сегодня мы поговорим об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Во-первых, сертификаты Solution User Certificates были заменены на VMCA Certificates (Intermediate CA), что сильно упростило управление инфраструктурой сертификатов для виртуальной среды:
Второй полезный момент - это интерфейс REST API для обработки сертификатов vCenter Server как часть общей стратегии по управлению всеми аспектами vSphere через API:
Также в vCenter Server и ESXi было сделано много улучшений, чтобы снизить число необходимых сертификатов для случаев, когда вы управляете ими вручную, либо автоматически с помощью центра сертификации VMware Certificate Authority (VMCA), который является частью vCenter.
VMCA - это полностью автономный и самодостаточный компонент для управления сертификатами для защищенной шифрованием виртуальной среды, исключая собственно сами сервисы и приложения в виртуальных машинах (для этого уже нужна инфраструктура PKI, в этом отличие VMCA от обычного CA).
В инфраструктуре vSphere 7 есть 4 способа управления сертификатами:
Fully Managed Mode - в этом случае на vCenter есть VMCA с новым корневым сертификатом. Этот режим используется для управления сертификатами внутри кластеров (защита коммуникации между хостами ESXi, а также между ESXi и vCenter). Для этого используются так называемые Machine Certificates. Сертификат VMCA root CA certificate можно загрузить с главной веб-страницы vCenter и импортировать его на свой компьютер для настройки траста. Также можно перегенерировать корневой VMCA-сертификат на базе собственной информации вместо дефолтной (вроде "VMware Engineering" и т.п.).
Hybrid Mode - если у вас слишком много пользователей, которые управляют элементами инфраструктуры vSphere, может оказаться непрактичным заставлять всех их импортировать корневые сертификаты на свои машины. Вместо этого вы можете заменить сертификат, который использует vSphere Client, чтобы браузеры принимали его по умолчанию. Однако администраторы vSphere могут по-прежнему хотеть импортировать корневой сертификат VMCA в целях настройки траста с хостами ESXi, чьи управляющие интерфейсы могут иметь сертификаты, подписанные со стороны VMCA. Как правило, команда администраторов не такая большая, поэтому для этого не требуется много усилий.
Надо понимать, что ни в режиме Fully Managed Mode, ни в Hybrid Mode не используются самоподписанные сертификаты. Все эти сертификаты подписаны со стороны VMCA как центра сертификации. Доверяя VMCA, мы безоговорочно доверяем и серверу VMware vCenter, что надо учитывать при планировании защиты виртуальной инфраструктуры.
Subordinate CA Mode - в этом режиме VMCA может оперировать как подчиненный центр сертификации, подчиняясь корпоративному CA. В этом режиме vCenter продолжает выполнять функции по автоматизации управления сертификатами как в режиме Fully Managed Mode, за исключением того, что они генерируются на стороне корпоративного центра сертификации. В этом случае надо уделять внимание процессу передачи сертификатов со стороны корпоративного CA на vCenter, так как в это время может произойти их подмена со стороны злоумышленника. Поэтому даже крупные организации, как правило, используют режим Hybrid Mode.
Full Custom Mode - в этом случае VMCA не используется для управления сертификатами, а администратор в ручном режиме занимается их генерацией и импортом. Это весьма экзотический сценарий, так как в этом случае придется управлять десятками и даже сотнями сертификатов, в зависимости от размера инфраструктуры. Это рождает большую вероятность человеческой ошибки. Возможно, этот вариант применим для каких-то особо секретных инфраструктур, где доверие людям больше, чем доверие ИТ-системам.
VMware в своей статье про сертификаты для vSphere 7 однозначно рекомендует использовать режим Hybrid Mode, если к нему в вашей инфраструктуре нет каких-либо противопоказаний или ограничений.
На сайте проекта VMware Labs вышло несколько небольших обновлений утилит для виртуальной инфраструктуры vSphere. Первое обновление - это новая версия USB Network Native Driver for ESXi 1.5. Напомним, что это набор драйверов для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии драйверов мы писали вот тут.
Сейчас в версии 1.5 поддерживаются следующие устройства:
Основная новая возможность - поддержка VMware vSphere 7. Будьте внимательны - для vSphere 7 сделан отдельный дистрибутив. Есть также и отдельные пакеты для vSphere 6.7 и 6.5.
Скачать USB Network Native Driver for ESXi можно по этой ссылке.
Второе небольшое обновление - это новая версия утилиты vSphere Software Asset Management Tool 1.1. С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии.
Из новых возможностей - новая таблица Host Inventory Table в генерируемом отчете software asset management, а также косметические исправления текстов. О первой версии утилиты мы писали вот тут.
Скачать vSphere Software Asset Management Tool можно по этой ссылке.
Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.
1. Больше нет vSphere Web Client на базе Flash
Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.
Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
2. Больше нет внешнего PSC (Platform Services Controller)
Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).
С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:
3. Больше нет VMware vCenter for Windows
Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.
VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:
Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.
4. Больше нет Update Manager Plugin
На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.
5. Больше нет VNC-сервера в ESXi
Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.
Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.
6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)
В эту категорию попали:
VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.
Вчера компания VMware объявила о доступности для загрузки (General Availability) своей флагманской платформы виртуализации VMware vSphere 7. Скачать ее можно по этой ссылке.
Объявление о доступности продукта было сделано во время почти часовой онлайн-сессии:
Одновременно стали доступны для скачивания и следующие решения:
RSS
